Designing a secure container image registry
https://gyazo.com/cd7ccd3bfc54d41e498013b3df86e816
コンテナイメージの構成
three-tier hierarcy: base image -> plat form image -> app image
Tier 1: base image
amazon linux2とかalpineとか。レジストリには複数のバージョンを登録するのが普通
オフィシャルアカウントから取得するのが普通
管理者はクラウドチーム、セキュリティチーム、あるいはオペチームによって運用される
ベースイメージにはまた、OSレベルの堅牢化を施す
タグはoriginal/upstreamなものと同じに。この場合、レジストリのtag immutability をオフにするのがよい
Tier 2: Platform Image
アプリ基盤をイメージ。開発者が日常で使う。
管理者はクラウドチーム、セキュリティチーム、あるいはオペチームによって運用される。
unpriviledged userにすること
タグはoriginal/upstreamなものと同じに。この場合、レジストリのtag immutability をオフにするのがよい
ダウンストリームアプリは、least specificなバージョンのすべき
例: node:14
(個人的意見: )go-alpineのようなイメージをベースにして、Tier 1 + Tier 2にするのはあり?
管理者が同じなのでありな気がする。Tier 2で、サービスごとに共通してインストールしたい内部パッケージがあるときなどには、Tier2とTier1を分離したほうがよさそう
あるいは、Tier1からgo-alpineにして、必要に応じてTier 2を作るとか。ベースイメージで存在するのであれば、こちらのがいいか。
Tier 3:
タグはgit hash, build番号やブランチを。
platformイメージから大きく変えないように
脆弱性スキャン
base imageにはclair/trivrでOSレベルの脆弱性をする
ぱっち
最低でも、30日ごとにbase imageをビルドしてパッチをあてること
↑にあわせてplatform imageは自動的にリビルトさせることが望ましい(applica tion imageも)
デプロイポリシー
内部レジストリのイメージであることを確認すること
opaとか、cloud custodianで